List the pull-request parameter the parity table does not carry (#55) - #156
Merged
iderex merged 1 commit intoAug 21, 2026
Merged
Conversation
This does not finish #55. Its remaining leg is the merge-method restriction, which is a ruleset parameter rather than a file in this tree. The table under `### The pull-request rule, parameter by parameter` opens by saying it carries every parameter the command above it prints. It carried eight rows and the command prints nine names: gh api repos/Flowfin/lab/rules/branches/main \ --jq '[.[] | select(.type=="pull_request") | .parameters | keys[]] | length' 9 `require_extra_approval_for_unattributed_changes` was the missing one, and it has never appeared anywhere in this tree: git grep -n 'require_extra_approval_for_unattributed_changes' origin/main exit=1 Both boards print `true` for it: gh api repos/Flowfin/lab/rules/branches/main \ --jq '.[] | select(.type=="pull_request") | .parameters.require_extra_approval_for_unattributed_changes' true gh api repos/Flowfin/jellyfin-plugin-sso/rules/branches/main \ --jq '.[] | select(.type=="pull_request") | .parameters.require_extra_approval_for_unattributed_changes' true What failure this prevents is a reader taking the table for the whole answer when a parameter that could ask for an approval at a review count of zero was not in it. The four review-adjacent rows all say they bite only where a review is required, and this one is not in that family, so its absence read as agreement with those four. The row says what the two commands say and claims nothing about what the parameter does. Whether it holds a merge at a count of zero is a statement about the platform, no command in this walk answers it, and the row says so rather than filling the gap with a guess. The other eight rows and the rule-type table above were re-read at the same time and every value still holds. How it was found: re-running the three commands the section prints, before quoting a row from it. Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
iderex
deleted the
parity/a-pull-request-parameter-the-table-does-not-list
branch
August 21, 2026 03:52
This was referenced Aug 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #55
What this changes
One row in the table under
### The pull-request rule, parameter by parameterin
docs/quality-parity.md, and two sentences above it saying what the row is.The table opens by saying it carries every parameter the command above it
prints. It carried eight rows. The command prints nine names, and it prints the
same nine at the target:
require_extra_approval_for_unattributed_changesis the one that was absent,and it has never appeared anywhere in this tree:
Both boards print
true:The means is Markdown in the document the walk already lives in, which is what
the issue asks for in its own words, so nothing here adds a format, a tool or a
place to look.
What failure it prevents
A reader taking the table for the whole answer while a parameter is outside it.
The four review-adjacent rows in that table each say they bite only where a
review is required, and none is required at a review count of zero. The missing
parameter is not in that family: it is written to ask for an approval where a
change carries commits the pull request's author is not credited with, so it is
the only one in the list that could ask for one at a count of zero. Absent from
the table, it read as agreeing with the four rows that say nothing bites.
The row states what the two commands print and claims nothing beyond that.
Whether the parameter actually holds a merge at a count of zero is a statement
about the platform, no command in this walk answers it, and the row says so
rather than filling the gap. It has never been observed to hold a merge on this
board.
What was run
At
cde3d912a9b1b945a7ea7916c1d70a828a670023, on Windows, with no graphicalsession and as an ordinary user:
go build,go vetandgofmt -leach printed nothing, which is the passingresult for all three.
The three commands the section itself prints were re-run before this change was
written, and the rule-type table and the enforcement and bypass paste still hold
exactly as written:
Every value in the other eight parameter rows still holds on both boards, read
from the same output as the key list above.
What this does not do
It does not finish #55. The remaining leg there is that the merge methods on
this board be restricted to
["merge"], and that is a ruleset parameter ratherthan a file in this tree, so nothing a pull request contains moves it:
It does not say what
require_extra_approval_for_unattributed_changesdoes. Itsays what both boards have it set to and that the walk does not answer the rest.
It does not restore the two sections of this same document that
d3edfc95b8526033c79cb26afe48282c2c090e32removed. Those belong to #26 and #62and are #155. This change adds a row well below both of them, so putting them
back is an insertion rather than a conflict, and #155 says to insert rather than
to take the whole file.
No second person has read this change. The evidence above stands in place of
that reading rather than beside it.